Implement RFC9728 - Support WWW-Authenticate header by MCP client #1071
Conversation
yurikunash
changed the title
yurikunash
changed the title
yurikunash
changed the title
|
Hi, Any updates on it ? @ihrpr we rely on correct parsing of Auth header |
|
@ihrpr Can we raise attention to this bug? It blocks the MCP client from correctly finding the resource metadata, leading to incorrect AS. Thank you |
src/mcp/client/auth.py
Outdated
| refresh_request = await self._refresh_token() | ||
| refresh_response = yield refresh_request | ||
| if response.status_code == 401: | ||
| if self.context.can_refresh_token(): |
There was a problem hiding this comment.
I'm not sure I agree with this part... if we know our current tokens are invalid, and we know we can refresh them, shouldn't we do that before sending a request we know is going to 401?
I think that would mean moving this if/else block ahead of line 526 where we yield request.
There was a problem hiding this comment.
Thank you for the suggestion @pcarleton
I was hesitant about it, so I implemented the "try first" approach, as it seemed more reliable.
As this article states, it's also perfectly fine to have that kind of optimization and refresh the token preemptively, so I updated the code as you proposed.
Resolves #1054
This PR implements proper WWW-Authenticate header parsing for protected resource metadata URL discovery as required by RFC9728 and the MCP specification. This change ensures full compliance with MCP authentication requirements and includes several related improvements to the authentication flow.
Changes Made
Primary Changes
Indirect Improvements
Motivation and Context
As per MCP specification:
This implementation was missing from the current MCP client, creating a gap in specification compliance that has real-world implications. The absence of proper WWW-Authenticate header handling prevents hosting multiple MCP servers that share the same domain but function as separate OAuth resources.
How Has This Been Tested?
The changes were verified by the comprehensive unit-test coverage for different scenarios, as well as simulating the Authorization scenario by executing the client locally.
Breaking Changes
Authorization Flow Change: The client now follows proper OAuth flow by sending an initial request to the resource and only performing authorization upon receiving a 401 status code. This aligns with OAuth specifications and security best practices.
Impact: Clients that relied on the previous behavior (where authorization was attempted regardless of initial response) may need to be updated. However, this change improves security and compliance with OAuth standards.
Migration: Most properly configured MCP servers should work without changes. Servers that expect immediate authorization without sending a 401 response should be updated to follow OAuth specifications.
Types of changes
Checklist
Additional context